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Abstract 


Since 1997, the Italian laws have recognized electronic delivery 
systems as legally usable. In 2005, after two years of technical 
tests, the characteristics of an official electronic delivery 
service, named certified electronic mail (in Italian "Posta 
Elettronica Certificata") were defined, giving the system legal 
standing. 


The design of the entire system was carried out by the National 
Center for Informatics in the Public Administration of Italy 
(DigitPA), followed by efforts for the implementation and testing of 
the service. The DigitPA has given the Italian National Research 
Council (CNR), and in particular the Institute of Information Science 
and Technologies at the CNR (ISTI), the task of running tests on 
providers of the service to guarantee the correct implementation and 
interoperability. This document describes the certified email system 
adopted in Italy. It represents the system as it is at the moment of 
writing, following the technical regulations that were written based 
upon the Italian Law DPR. November 2, 2005. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 
(IETF). It has been approved for publication by the Internet 
Engineering Steering Group (IESG). Not all documents approved by the 
IESG are a Candidate for any level of Internet Standard; see Section 
2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc6109. 
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db 


Introduction 


Since 1997, the Italian laws have recognized electronic delivery 
systems as legally usable. In 2005, after two years of technical 
tests, the characteristics of an official electronic delivery 
service, named certified electronic mail (in Italian Posta 
Elettronica Certificata, from now on "PEC") were defined, giving the 
system legal standing. 


This document represents the English version of the Italian 
specifications 
(http://www.digitpa.gov.it/sites/default/files/normativa/ 
Pec_regole_tecniche_DM_2-nov-2005.pdf); the Italian version is the 
normative PEC reference. 


IETF review did not result in community consensus. Since this 
specification describes existing deployment and implementation, the 
issues identified by the IETF community have not been addressed in 
this document. However, these issues would need to be addressed 
before a successor to this document could be published. Ata 
minimum, the successor document would need to include: 


* A clear statement of the requirements/goals that need to be 
satisfied by the protocol; 


* A comprehensive diagram and description of the overall message flow 
and delivery sequence required to achieve the requirements; 


* Alignment with traditional terminology for IETF email and security 
* A review of prior art; and 


* A replacement of the unregistered LDAP DN name space used in this 
specification, which may lead to conflict with other registered or 
unregistered names, with a registered name space. 


1. Scope 


To ensure secure transactions over the Internet, cryptography can be 
associated with electronic messages in order to provide some 
guarantee on sender identity, message integrity, confidentiality, and 
non-repudiation of origin. Many end-to-end techniques exist to 
accomplish such goals, and some offer a high level of security. The 
downside of end-to-end cryptography is the need for an extensive 
penetration of technology in society, because it is essential for 
every user to have asymmetric keys and certificates signed by a 
Certification Authority. Along with that, users would need to have 
an adequate amount of knowledge regarding the use of such technology. 
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PEC, on the other hand, uses applications running on servers to 
digitally sign messages, thus avoiding the complexity end-to-end 
systems bring about. By doing so, the user need only have an 
ordinary mail client with which to interact. The downside is that 
the level of security drops, since the protection does not cover the 
entire transaction. Nonetheless, application is simpler and does not 
require specific user skills, making it easily more widespread among 
users. 


This document describes PEC’s technical aspects and features. It 
presents the details of the protocol and the messages that are sent 
between service providers, introducing the system adopted by the 
Italian government for the exchange of certified emails. 


1.2. Notational Conventions 

1.2.1. Requirement Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in [REQ]. 


1.2.2. Acronyms 


CMS: Cryptographic Message Syntax 

CNIPA: Italian National Agency for Digital Administration 
(Centro Nazionale per 1’Informatica nella Pubblica 
Amministrazione) 

CNR: Italian National Research Council (Consiglio Nazionale 
delle Ricerche) 

CRL: Certificate Revocation List 

CRL DP: Certificate Revocation List Distribution Point 

DNS: Domain Name Service 

DTD: Document Type Definition 

FQDN: Fully Qualified Domain Name 

LST Ts The Institute of Information Science and Technologies 


at the CNR (Istituto di Scienza e Tecnologie 
dell’Informazione "A.Faedo") 


LDAP: Lightweight Directory Access Protocol 

LDIF: LDAP Data Interchange Format 

MIME: Multipurpose Internet Mail Extensions 

PEC: Certified Electronic Mail (Posta Elettronica 
Certificata) 

S/MIME: Secure/MIME 

SMTP: Simple Mail Transfer Protocol 

TLS: Transport Layer Security 

XML: eXtensible Markup Language 
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1.2.3. Terminology and Definitions 


Certification data: A set of data certified by the sender’s PEC 
provider that describes the original message. It includes the date 
and time of dispatch, sender email address, recipient(s) email 
address(es), subject, and message identifier. 


Certified electronic mail: A service based on electronic mail, as 
defined by the [EMAIL] and [SMTP] standards and extensions, which 
permits the transmission of documents produced with informatics 
tools. 


DigitPA: Ex-CNIPA. 
Holder: The person or organization to whom a PEC mailbox is assigned. 


Message sent: A PEC message is considered sent when the sender’s PEC 
provider, after several checks, accepts the email and returns a 
server-user acceptance PEC notification to the sender. 


Message received: A PEC message is considered received when it is 
stored in the receiver’s mailbox, after which the receiver PEC 
provider returns a delivery PEC notification to the sender. 


Msgid: Is the message identifier generated by the email client, as 
defined in [EMAIL], before the message is submitted to the PEC 
system. 


Ordinary mail: Non-PEC email messages. 
Original message: Is the user-generated message before its arrival to 


the sender Access Point. The original message is delivered to the 
recipient inside a PEC transport envelope. 


PEC domain: Corresponds to a DNS domain dedicated to the holders’ 
mailboxes. 


PEC mailbox: An electronic mailbox for which delivery PEC 
notifications are issued upon reception of PEC messages. Such a 


mailbox can be defined exclusively within a PEC domain. 


PEC msgid: Is a unique identifier generated by the PEC system, which 
will substitute the msgid. 
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PEC provider: The entity that handles one or more PEC domains with 
their relative points of Access, Reception, and Delivery. It is the 
holder of the key that is used for signing PEC notifications and 
envelopes, and it interacts with other PEC providers for 
interoperability with other holders. 


PEC provider’s key: Is a key released by DigitPA to every PEC 
provider. It is used to sign PEC notifications and envelopes and to 
authorize access to the PEC providers directory. 


PEC providers directory: Is an LDAP server positioned in an area 
reachable by all PEC service providers. It constitutes the technical 
structure related to the public list of PEC service providers and 
contains the list of PEC domains and service providers with relevant 
certificates. 


Service mailbox: A mailbox for the sole use of the provider, 


dedicated for the reception of server-server acceptance and virus 
detection PEC notifications. 


Time stamp: Digital evidence with which a temporal reference, that 
can’t be repudiated, is attributed to one or more documents. 


2. PEC Model 
2.1. System-Generated Messages 
The PEC system generates messages in MIME format composed of a 


descriptive textual part and other [MIME1] parts, the number and 
content of which varies according to the type of message generated. 


A system-generated message falls into one of the following 
categories: 


o Notifications; 
o Envelopes. 


The message is inserted in an S/MIME v3 structure in CMS format and 
signed with the PEC provider’s private key. The X.509v3 certificate 
associated with the key MUST be included in the aforementioned 
structure. The S/MIME format used to sign system-generated messages 
is the "multipart/signed" format (.p7s), as described in section 
3.4.3 of [SMIMEV3]. 


To guarantee the verifiability of signatures on as many mail clients 


as possible, X.509v3 certificates used by certified email systems 
MUST abide by the profile found in section 6.5. 
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In order for the receiving mail client to verify the signature, the 
sender address MUST coincide with the one indicated within the 
X.509v3 certificate. For this mechanism, PEC transport envelopes 
MUST indicate in the "From:" field a single author’s address which is 
different from the one contained in the original message. To allow 
for better message usability by the receiving user, the author’s mail 
address in the original message is inserted as a "display name". For 
example, a "From:" field such as: 


From: "John Smith" <john.smith@domain.example.com> 


would result in the following "From:" value in the respective PEC 
transport envelope: 


From: "On behalf of: john.smith@domain.example.com" 
<certified-mail@provider.example.com> 


Both "From:" and "Sender:" fields MUST contain the same value. In 
order for replies to be correctly sent back to the proper 
destination, the "Reply-To:" field in the PEC transport envelope MUST 
contain the same unaltered value of the original message’s 
"Reply-To:" field. When it is not explicitly specified in the 
original message, the system that generates the PEC transport 
envelope creates it by extracting the information from the "From:" 
field in the original message. 


When PEC notifications are sent, the system MUST use the original 
message sender's address as the destination address, as is specified 
in the reverse path data of the SMTP protocol. PEC notifications 
MUST be sent to the sender’s PEC mailbox without taking into account 
the "Reply-To:" field, which might be present in the original 
message's header. 


All system-generated PEC messages are identifiable for having a 
specific header defined in PEC according to the type of message 
generated. 


To determine the certification data, the elements used for the actual 
routing of the message are employed. In SMTP dialog phases, the 
reverse path and forward path data ("MAIL FROM" and "RCPT TO" 
commands) are thus considered certification data of both the sender 
and the recipients, respectively. Addressing data present in the 
message body ("To:" and "Cc:" fields) are used solely in order to 
discriminate between primary and carbon copy recipients when 
necessary; addressing data present in the "Bcc:" field MUST be 
considered invalid by the system. 
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2.1.1. Message Types 


All system-generated messages inherit their header fields and values 
from the original message, with extra fields added according to the 
type of message generated. 


2.1.1.1. PEC Notifications 
They have the purpose of informing the sending user and interacting 
providers of the progress the message is making within the PEC 
network. 

2.1.1.1.1. Success PEC Notifications 
These notifications indicate an acknowledgment on the provider’s side 
for the reception or handling of a PEC message. More specifically, 
it can indicate one of three situations: server-user acceptance, 
server-server acceptance, or delivery. 


Added header fields are: 


o X-Ricevuta: 


o X-Riferimento-Message-ID: 


The field "X-Ricevuta:" indicates the type of PEC notification 
contained in the message, whereas "X-Riferimento-Message-ID:" 
contains the message identifier generated by the mail client (msgid). 


Body contents differ according to notification type. This is 
described more thoroughly in section 3. 


o A server-user acceptance PEC notification informs the user that 
his provider has accepted the message and will be taking care of 
passing it on to the provider(s) of the addressee(s). 


o A server-server acceptance PEC notification is an inter-provider 
communication only, it MUST NOT be sent to the users. With this 
notification, the receiving provider simply informs the sending 
one that it has received a PEC message, and will take the 
responsibility of forwarding it to the addressee(s). From then 
on, the sender provider is no longer held responsible as to the 
whereabouts of the message, but is limited to notifying its user 
of the success or failure of delivery. 


o Delivery PEC notifications take place as the final communication 


of a transaction, indicating overall success in handing the 
message over to the addressee(s). 
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2.1.1.1.2. Delay PEC Notifications 


Delay PEC notifications are sent out 12 hours after a message has 
been dispatched from the sending provider, and no server-server 
acceptance or delivery PEC notification has been received. These 
have the sole purpose of notifying the user of the delay. 


If another 12 hours go by without any sign of a server-server 
acceptance or delivery PEC notification (amounting to a 24-hour 
delay), another delay PEC notification is dispatched to the user 
informing him of the possible delivery failure. The provider will 
not keep track of the delay any further. 


2.1.1.1.3. Failure PEC Notifications 
They are sent when there is some error in transmission or reception. 


More specifically, a failure PEC notification can indicate either a 
formal-exception error or a virus detection. 


Added header fields are: 
o X-Ricevuta: 


o X-Riferimento-Message-ID: 


o X-VerificaSicurezza: [optional] 

"X-Ricevuta:" and "X-Riferimento-Message-ID:" have the same role as 
indicated in section 2.1.1.1.1 (Success Notifications). 
"X-VerificaSicurezza:" (security verification) is an optional header 


field, used for virus-related PEC notifications. 


Body contents differ according to notification type. This is 
described more thoroughly in section 3. 


2.1.1.2. PEC Envelopes 
Messages entering the PEC network are inserted within specific PEC 
messages, called envelopes, before they are allowed to circulate 
further within the network. These envelopes MUST inherit the 
following header fields, along with their unmodified values, from the 
message itself: 
o Received: 


o To: 


o Cc: 
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o Return-Path: 


o Reply-To: (if present) 


April 2011 


Depending on the type of message requesting admission into the PEC 


network, 
PEC anomaly envelope. Distinction will be possib 
addition of the "X-Trasporto:" header field. 


it will be inserted in either a PEC transport envelope or a 


le through the 


2.2. Basic Structure 
fortet + Pheata + 
| Fes | | | 
| | AP | | PEC | | 
+----+ | +--+ | messages & | +---+ +--+ | +----+ 
|user|<--> ii bd > | InP | |DP | <-->|user| 
+----+ +--+ +---+ notifications +---+ +--+ +----+ 
| |pe| |Ine] | | | 
| +--+ ++ | | | 
=== == 5=5=2= + +------------ + 
PEC PEC 
sender receiver 
provider provider 
where: 
AP = Access Point 
DP = Delivery Point 
InP = Incoming Point 
2.2.1. Access Point 


This is what the user client at the sender side interacts with, 


giving the user access to PEC services set up by 


the provider. 


Such access MUST be preceded by user authentication on the system 


(see section 5.2). 


The Access Point receives the original messages 


its user wishes to send, 
to the outcome: 


o if the message passes 


runs some formal checks, 


all checks, 


and acts according 


the Access Point generates a 


server-user acceptance PEC notification and inserts the original 
message inside a PEC transport envelope; 


if a formal exception is detected, the Access Point refuses the 


message and emits the relevant non-acceptance PEC notification 


(see section 3.1.1); 
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o if a virus is detected, the Access Point generates a non- 
acceptance PEC notification and inserts the original message as is 
in the provider’s special store. 


Generation of the server-user acceptance notification indicates to 
the user that the message was accepted by the system, certifying also 
the date and time of the event. The notification MUST contain user- 
readable text, and an XML part containing the certification data. 

The notification MAY also contain other attachments for extra 
features offered by the provider. 


Using the data available in the PEC providers directory (see section 
4.5), the Access Point runs checks on every recipient in the "To:" 
and "Cc:" fields present in the original message to verify whether 
they belong to the PEC infrastructure or to non-PEC domains. Such 
checks are done by verifying the existence, through a case- 
insensitive search, of the recipients’ domains in the 
"managedDomains" attribute found within the PEC providers directory. 
Therefore, the server-user acceptance PEC notification (and relevant 
certification data) relates to, for each address, the typology of its 
domain; PEC or non-PEC. 


The message identifier (PEC msgid) of accepted original messages 
within the PEC infrastructure MUST be unambiguous in order to consent 
correct tracking of messages and relative PEC notifications. The 
format of such an identifier is: 


[alphanumeric string]@[provider mail domain] 
or: 
[alphanumeric string]@[FQDN mail server] 


Therefore, both the original message and the corresponding PEC 
transport envelope MUST contain the following header field: 


Message-ID: <[unique identifier]> 


When an email client that is interacting with the Access Point has 
already inserted a message identifier (msgid) in the original 
message, that msgid SHALL be substituted by a PEC msgid. In order to 
allow the sender to link the message sent with the relative PEC 
notifications, the msgid MUST be inserted in the original message as 
well as the relative PEC notifications and transport envelope. If 
present, the msgid is REQUIRED in the original message's header by 
adding the following header field: 


X-Riferimento-Message-ID: <[msgid]> 
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which will also be inserted in the PEC transport envelope and 
notifications, and related in the certification data (see section 
4.4). 


2.2.2. Incoming Point 


This point permits the exchange of PEC messages and notifications 
between PEC providers. It is also the point through which ordinary 
mail messages can be inserted within the system of certified mail. 


The exchange of messages between providers takes place through SMTP- 
based transactions, as defined in [SMTP]. If SMTP communication 
errors occur, they MAY be handled using the standard error 
notification mechanisms, as provided by SMTP in [SMTP] and 
[SMTP-DSN]. The same mechanism is also adopted for handling 
transitory errors, that result in long idling periods, during an SMTP 
transmission phase. In order to guarantee that an error is returned 
to the user, as defined in section 3.3.3, the system that handles PEC 
traffic MUST adopt a time limit for message idleness equal to 24 
hours. 


Once a message arrives, the Incoming Point runs the following list of 
checks and operations: 


o verifies correctness and type of the incoming message; 


o if the incoming message is a correct and undamaged PEC transport 
envelope: 


- emits a server-server acceptance PEC notification towards the 
sender provider (section 3.2.1); 


- forwards the PEC transport envelope to the Delivery Point 
(section 3.3). 


o if the incoming message is a correct and undamaged PEC 
notification, forwards the notification to the Delivery Point. 


o if the incoming message does not conform to the prerequisites of a 
correct and undamaged PEC transport envelope or notification, but 
comes from a PEC provider, i.e., passes the verifications 
regarding existence, origin, and validity of the signature, then 
the message MUST be propagated towards the recipient. 


Therefore, the Incoming Point: 


- inserts the incoming message in a PEC anomaly envelope (section 
CAD E 
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- forwards the PEC anomaly envelope to the Delivery Point. 


o if the incoming message does not originate from a PEC system, 
i.e., fails verifications regarding existence, origin, and 
validity of the signature, then the message will be treated as 
ordinary email, and, if propagated to the recipient: 


- is inserted in a PEC anomaly envelope (section 3.2.2); 


- the PEC anomaly envelope is forwarded to the Delivery Point. 


The server-server acceptance PEC notification is generated by the 
receiving provider and sent to the sending provider. Its purpose 
is to keep track of the message in its transition from one 
provider to another, and is therefore strictly intra-provider 
communication; the end user knows nothing about it. 


To check the correctness and integrity of a PEC transport envelope 
or notification, the Incoming Point runs the following tests: 


o Signature existence - the system verifies the presence of an 
S/MIME signature structure within the incoming message; 


o Signature origin - the system verifies whether or not the 
signature belongs to a PEC provider by extracting the certificate 
used for signing and verifying its presence in the PEC providers 
directory. To ease the check, it is possible to calculate the 
certificate's [SHA1] hash value and perform a case-insensitive 
search of its hexadecimal representation within the 
"providerCertificateHash" attribute found in the PEC providers 
directory. This operation allows one to easily identify the 
sender provider for subsequent and necessary matching checks 
between the extracted certificate and the one present in the 
provider’s record; 


o Signature validity - S/MIME signature correctness is verified by 
recalculating the signature value, checking the entire 
certification path, and verifying the [CRL] and temporal validity 
of the certificate. In case some caching mechanism is used for 
CRL contents, an update interval MUST be adopted so that the most 
up-to-date data is guaranteed, thus minimizing the possible delay 
between a publication revocation by the Certification Authority 
and the variation acknowledgment by the provider; 


o Formal correctness - the provider performs sufficient and 
necessary checks to guarantee that the incoming message is 
compliant with the formats specified in this document (PEC 
transport envelope and notifications). 
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If a virus-infected PEC transport envelope passes the checks just 
mentioned, it is still considered correct and undamaged. The 
presence of the virus will be detected in a second phase, during 
which the contents of the PEC transport envelope are verified. 
Thus, the Incoming Point will refrain from forwarding the message 
to the recipient, instead sending the appropriate PEC notification 
of non-delivery and storing the virus-infected message in the 
provider’s special storage. 


In case ordinary mail messages are received, the PEC provider 
SHALL perform virus checks in order to prevent the infiltration of 
potentially dangerous mail messages within the PEC system. If a 
virus is detected in an ordinary mail message, the latter can be 
discarded at the Incoming Point before it enters the PEC system. 
In other words, no special treatment is reserved for the error; it 
is handled in a manner that is conformant to the procedures 
usually followed for messages going through the Internet. 


When the receiving provider detects a virus inside a PEC transport 
envelope during the reception phase, it emits a virus detection 
PEC notification to the sending provider, which then realizes its 
checks failed to detect that virus. When this happens, the 
sending provider MUST: 


o check what virus typologies were not detected by its own antivirus 
to verify the possibility of interventions 


o send a virus-induced non-delivery PEC notification to the sender’s 
mailbox. 


2.2.3. Delivery Point 


This point is the point that receives messages from the Incoming 
Point and forwards them to the final recipient. 


It MUST run a series of tests on received messages before forwarding 
them to the user (see section 3.3.1). It first verifies the typology 
of the message and decides whether or not a PEC notification should 
be issued to the sender. The delivery PEC notification (section 
3.3.2) is emitted after the message was delivered to the recipient’s 
PEC mailbox and only at reception of a valid PEC transport envelope 
(sections 2.2.2 and 3.1.5). 


In all other cases, such as PEC anomaly envelopes and PEC 
notifications, the delivery PEC notification is not emitted. 
Regardless, the message received from the Delivery Point MUST be 
delivered unmodified to the recipient’s mailbox. 
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2 


2 
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The delivery PEC notification indicates to the sender that the 
message sent was in fact conveyed to the specified recipient’s 
mailbox and certifies the date and time of delivery through use of 
user-readable text and an XML part containing certification data, 
along with other possible attachments added for extra features 
offered by the provider. 


If a PEC transport envelope received at the Delivery Point can't be 
delivered to the destination mailbox, the Delivery Point emits a non- 
delivery PEC notification (section 3.3.3). If, on the other hand, 
the delivery error concerns a message that arrives from Internet 
(i.e., a non-PEC message), no such notification is emitted. 


.2.4. Storage 


Each provider MUST dedicate a special storage for the deposition of 
any virus-infected messages encountered. Whether the virus be 
detected by the sender’s Access Point or the receiver's Incoming 
Point, the provider that detects it MUST store the mail message in 
its own storage, and keep it for 30 months. 


.2.5. Provider Service Mailbox 


For exclusive use of the provider, dedicated to the reception of PEC 
notifications in two cases only: 


o server-server acceptance notification; and 


o virus detection notification. 


.2.6. Provider Service Email Address 


Each provider MUST register a special purpose email address for use 
when sending PEC transport envelopes and notifications, as delineated 
in section 3. This address MAY coincide with that of the service 
mailbox described in section 2.2.5. 


.3. Log 


The server administrator MUST keep track of any and all operations 
carried out in a specific message log file. The information kept in 
the log for each operation is the following: 

o message identifier (msgid) 


o date and time of event 


o sender of original message 
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o 


o 


recipient (s) of original message 
subject of original message 


event type (reception, delivery, PEC notification emission, etc.) 
message identifiers of related generated messages 


sending provider 


The service provider MUST store this data and preserve it unmodified. 
Italian laws have specified that the service provider retain the data 
for 30 months. 


3. Message Processing 


JLo. 


Access Point 


The Access Point acts as a submission service as defined in 
[SUBMISSION]. 


3 deeds 


Formal Checks on Messages 


When the Access Point receives a message the user wishes to send, it 
MUST guarantee said message's formal conformity as defined in 
[EMAIL], and verify that the: 


o 


[EMAIL] header section contains a "From:" header field holding an 
[EMAIL] compliant email address; 


[EMAIL] header section contains a "To:" header field holding one 
or more [EMAIL] compliant email addresses; 


sender's address, specified in the SMTP reverse path, coincides 
with the one in the message's "From:" header field; 


recipients” addresses specified in the SMTP forward path coincide 
with the ones present in the "To:" or "Cc:" header fields of the 
message; 


"Bcc:" header field does not contain any value; 


total message size falls within the limits accepted by the 
provider. Such limits apply depending on the number of recipients 
as well; by multiplying it to the message size, the outcome MUST 
fall within the limits accepted by the provider. Italian laws 
have specified this limit as being 30 MB. 
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If the message does not pass the tests, the Access Point MUST NOT 
accept the message within the PEC system, thus emitting the relative 
PEC notification of non-acceptance. 


3.1.2. Non-Acceptance PEC Notification Due to Formal Exceptions 


When the Access Point cannot forward the message received due to 
failure in passing formal checks, the sender is notified of such an 
outcome. If the error is caused by the message failing size checks, 
a non-acceptance PEC notification is sent as long as the size remains 
bound by a certain limit. If the size exceeds said limit, error 
handling is left to SMTP. 


The notification header will contain the following fields: 


X-Ricevuta: non-accettazione 

Date: [date of notification emission] 

Subject: AVVISO DI NON ACCETTAZIONE: [original subject] 
From: posta-certificata@[mail domain] 

To: [original sender] 

X-Riferimento-Message-ID: [msgid] 


The notification body will contain a text part that constitutes the 
actual notification in readable format according to a model that 
relates the following information: 


Error in message acceptance 

On [date] at [time] ([time zone]), in the message "[subject]" 
originating from "[original sender]" and addressed to: 
[recipient_1] 

[recipient_2] 

[recipient_n] 

a problem was detected that prevents its acceptance due to 
[error description]. 

The message was not accepted. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelope] 


The same certification information is inserted in an XML file to be 
added to the notification body, thus allowing automatic checks on the 
message (section 4.4). Parsing MUST be done on the XML part only. 
Additional parts MAY be included by the provider for provider- 
specific services. Regardless, the original message MUST NOT be 
included. The message MUST follow the format described in section 
423). 
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3.1.3. Non-Acceptance PEC Notification Due to Virus Detection 


The Access Point MUST run some tests on the content of messages it 
receives from its users and reject them if a virus is detected. In 
which case, a virus-detection-induced non-acceptance PEC notification 
MUST be emitted to clearly inform the user of the reason the message 
was refused. 


The notification header contains the following fields: 


X-Ricevuta: non-accettazione 

X-VerificaSicurezza: errore 

Date: [notification emission date] 

Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [original 


subject] 
From: posta-certificata@[mail domain] 
To: [original sender] 


X-Riferimento-Message-ID: [msgid] 


The body contains a readable text part according to the following 
model: 


Error in message acceptance due to virus presence 

On [date] at [time] ([time zone]), in the message "[subject]" 
originating from "[original sender]" and addressed to: 
[recipient_1] 

[recipient_2] 

[recipient_n] 

a security problem was detected [ID of detected content type]. 
The message was not accepted. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelope] 


The same certification data is inserted in an XML file added to the 
notification to allow for automatic checks (section 4.4). Parsing 
MUST be done on the XML part only. Additional parts MAY be included 
by the provider for provider-specific services. Regardless, the 
original message MUST NOT be included. The message MUST follow the 
format described in section 4.3. 


3.1.4. Server-User Acceptance PEC Notification 
The server-user acceptance PEC notification is a message sent to the 


sender by his server, containing date and time of message acceptance 
into the system, sender and recipient data, and subject. 
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The header contains the following fields: 


X-Ricevuta: accettazione 

Date: [actual date of server-user acceptance] 
Subject: ACCETTAZIONE: [original subject] 
From: posta-certificata@[mail domain] 

To: [original sender] 
X-Riferimento-Message-ID: [msgid] 


The message body contains a text part that constitutes the 
notification in readable format, according to a model that relates 


the following information: 


Server-User Acceptance PEC notification 


On [date] at [time] ([time zone]), the message "[subject]" 
originating from "[original sender]" and addressed to: 
[recipient_1] (["certified mail" | "ordinary mail"]) 
[recipient_2] (["certified mail" | "ordinary mail"]) 
[recipient_n] (["certified mail" | "ordinary mail"]) 


was accepted by the system and forwarded to the recipient (s). 
Message identifier: [PEC msgid of corresponding 
PEC transport envelope] 
The same certification data is inserted in an XML file added to the 
notification message, allowing automatic checks on it (section 4.4). 
Parsing MUST be done on the XML part only. Additional parts MAY be 
included by the provider for provider-specific services. The message 
MUST follow the format described in section 4.3. 
3.1.5. PEC Transport Envelope 


A PEC transport envelope is a message generated by the Access Point 
that contains the original message as well as certification data. 


As mentioned in section 2.1.1.2, the PEC transport envelope inherits 
from the original message the values of the following header fields, 
which MUST be related unmodified: 

o Received: 

o To: 

o «Ci 


o Return-Path: 


o Reply-To: (if present) 
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On the other hand, the following fields MUST be modified, or inserted 
if necessary: 


X-Trasporto: posta-certificata 
Date: [actual date of server-user acceptance] 
Subject: POSTA CERTIFICATA: [original subject] 
From: "On behalf of: [original sender]" 

<certified-mailf [mail_domain]> 
Reply-To: [original sender] (inserted only if not present) 
Message-ID: [PEC msgid generated as in section 2.2.1] 
X-Riferimento-Message-ID: [msgid] 
X-TipoRicevuta: [completa/breve/sintetica] 


The "X-TipoRicevuta:" field indicates the type of delivery PEC 
notification the sender wishes to receive -- complete, brief, or 
concise. 


The body of the PEC transport envelope contains a text part that 
constitutes the readable format of the message according to a model 
that relates the following certification data: 


Certified mail message 

On [date] at [time] ([time zone]), the message "[subject]" was 
sent by "[original sender]" and addressed to: 

[recipient_1] 

[recipient_2] 

[recipient_n] 

The original message is included in attachment. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelopel 


Within the PEC transport envelope, the entire, non-modified original 
message is inserted in a format compliant with [EMAIL] (except for 
what has been said regarding the message identifier), as well as an 
XML part, which contains the certification data that was already 
related in text format, and information on the type of message and 
PEC notification requested (section 4.4). Parsing MUST be done on 
the XML part only. Additional parts MAY be included by the provider 
for provider-specific services. The message MUST follow the format 
described in section 4.3. 


Note that the routing data of the PEC transport envelope (forward and 
reverse paths) remain unaltered. 
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3.1.6. Timeout Delivery Error PEC Notification 


If the sending provider doesn’t receive a server-server acceptance or 
delivery PEC notification from the receiving provider within 12 hours 
of the message dispatch, it informs the user that the recipient’s 
provider might not be able to deliver the message. In case the 
sending provider doesn’t receive a delivery PEC notification within 
24 hours after message dispatch, it emits another non-delivery PEC 
notification to the user by the 24-hour timeout, but not before 22 
hours have passed. 


Such a communication takes place through a PEC notification of non- 
delivery due to timeout, the header of which contains the following 
fields: 


X-Ricevuta: preavviso-errore-consegna 

Date: [date of notification emission] 

Subject: AVVISO DI MANCATA CONSEGNA PER SUP. TEMPO MASSIMO: 
[original subject] 

From: posta-certificata@[mail domain] 

To: [original recipient] 

X-Riferimento-Message-ID: [msgid] 


The body of the first non-delivery PEC notification (12-hour timeout) 
contains a text part that represents the readable format of the 


notification which will relate the following data: 


Non-delivery PEC notification 


On [date] at [time] ([time zone]), the message 
"[subject]" originating from "[original sender]" 
and addressed to "[recipient]" 


has not been delivered within the first 12 hours following 

its dispatch. Not excluding that the message might eventually 
be delivered, it is deemed useful to consider that dispatch 
might not have a positive outcome. The system will see to 
sending another non-delivery PEC notification if in the 
following twelve hours no confirmation is received from the 
recipient. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelope] 


On the other hand, 24-hour-timeout induced PEC notifications, which 


have the same header as described above, will have the following text 
in their body: 
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Non-delivery PEC notification 

On [date] at [time] ([time zone]), the message 
"[subject]" originating from "[original sender]" 

and addressed to "[recipient]" 

has not been delivered within 24 hours of its dispatch. 


The transaction is deemed to be considered terminated with a 
negative outcome. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelope] 


The same certification data is inserted in an XML file added to both 
PEC notification types to allow automatic checks (section 4.4). 


Parsing MUST be done on the XML part only. Additional parts MAY be 
added for services supplied by the PEC provider. Regardless, the 
original message MUST NOT be included. The message MUST follow the 
format described in section 4.3. 


A timeout PEC notification is generated if one of the following 
scenarios occurs: 


o the sending provider receives a server-server acceptance PEC 
notification during the first 12 hours following message dispatch, 
but does not receive a delivery PEC notification at all. In this 
case, it would be a 24-hour timeout PEC notification. 


o the sending provider does not receive a server-server acceptance 
PEC notification, but receives a delivery PEC notification after 
12 hours and before the 24-hour timeout. In this case it would be 
a 12-hour timeout PEC notification. 


o the sending provider doesn’t receive either a server-server 
acceptance or a delivery PEC notification. In this case, two 
timeout PEC notifications are generated; a 12-hour and a 24-hour 
timeout PEC notification. 


3.2. Incoming Point 
3.2.1. Server-Server Acceptance PEC Notification 


When correct PEC transport envelopes (as defined in section 2.2.2.) 
are exchanged between PEC providers, the receiver MUST send a server- 
server acceptance PEC notification to the sender. The single 
dispatched notification concerns all recipients who belong to the 
same provider, and to whom the incoming message was addressed, as 
stated in the routing data (forward and reverse paths) of the SMTP 
transaction. Within the certification data of a single server-server 
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acceptance PEC notification, all recipients of the message to which 
it refers are listed. In general, when receiving a PEC transport 
envelope, each provider MUST emit one or more server-server 
acceptance PEC notifications to cover, in absence of SMTP transport 
errors, all the recipients in its jurisdiction. 


The header of a server-server acceptance PEC notification contains 
the following fields: 


X-Ricevuta: presa-in-carico 

Date: [date of server-server acceptance] 
Subject: PRESA IN CARICO: [original subject] 
From: posta-certificatal [mail domain] 

To: [sender provider service mailbox] 
X-Riferimento-Message-ID: [msgid] 


The provider's service email address is obtained from the PEC 
providers directory during the necessary queries made in the 
signature verification stage. 


The body contains a text part that follows the underlying model: 


Server-server acceptance PEC notification 

On [date] at [time] ([time zone]), the message "[subject]" 
originating from "[original sender]" and addressed to: 
[recipient_1] 

[recipient_2] 

[recipient_n] 

was accepted by the system. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelopel 


The same certification data is inserted in an XML file which is added 
to the notification message to allow for automatic checks (section 
4.4). Parsing MUST be done on the XML part only. Additional parts 
MAY be added by the provider for provider-specific services. The 
message MUST follow the format described in section 4.3. 


3.2.2. PEC Anomaly Envelope 


If the tests on an incoming message detect an error, or the message 
is identified as being ordinary mail and the provider is set to 
forward it to the recipient, the system MUST insert such a message in 
a PEC anomaly envelope. Before delivery, the entire message received 


Petrucci, et al. Informational [Page 25] 


RFC 6109 Certified Electronic Mail April 2011 


at the Incoming Point is inserted in a format compliant with [EMAIL] 
as a [MIME1] part inside a new message that MUST inherit the 
unmodified values for the following header fields from the received 
message: 


o Received: 

o To: 

o Cc: 

o Return-Path: 
o Message-ID: 


Whereas, the following header fields MUST be modified or inserted: 


X-Trasplorto: errore 
Date: [mlessage arrival date] 
Subject: ANOMALIA MESSAGGIO: [original subject] 
From: "On behalf of: [original sender]" 
<posta-certificata@[mail_domain]> 
Reply-To: [original sender (inserted only if not already 
present) ] 


The body contains a user-readable text part according to a model that 
relates the following data: 


Message anomaly 

On [date] at [time] ([time zone]), the message "[subject]" 
originating from "[original sender]" and addressed to: 
[recipient_1] 

[recipient_2] 

[recipient_n] 

was received. 

The data has not been certified due to the following error: 
[concise description of error] 

The original message is attached. 


Due to uncertainty regarding origin and/or conformity of the message 
received, the PEC anomaly envelope MUST NOT contain [MIME1] parts 
other than the entire message that arrived at the Incoming Point. 


Note that the routing data of such an envelope (forward and reverse 
paths) remain unaltered. Doing so guarantees both message forwarding 
to the recipients, and reception of SMTP error notifications, if any 
occur, by the sender (as specified in [SMTP] and [SMTP-DSN]). 
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3.2.3. Virus Detection PEC Notification 


If the Incoming Point receives virus-infected PEC messages, it MUST 
NOT forward them. Rather it MUST inform the sending provider, which 
will in turn inform the sending user, of the failed transmission. A 
separate PEC notification of virus detection MUST be sent on behalf 
of every recipient within the provider’s domain. 


In case a virus is detected during the reception phase of a message 
whose origin was asserted through sender signature verification, the 
system generates a virus-detected PEC notification indicating the 

error found, and sends it to the sending provider’s service mailbox. 


The header of this PEC notification contains the following fields: 


X-Ricevuta: rilevazione-virus 

X-Mittente: [original sender] 

Date: [date of notification emission] 

Subject: PROBLEMA DI SICUREZZA: [original subject] 
From: posta-certificata@[mail domain] 

To: [sender provider notifications] 
X-Riferimento-Message-ID: [msgid] 


The body contains a readable text part according to a model that 
relates the following data: 


Virus detection PEC notification 


On [date] at [time] ([time zone]), in the message "[subject]" 
originating from "[original sender]" and addressed to 
"[recipient]" 


a security problem was detected [ID of content type detected]. 
Message identifier: [PEC msgid of corresponding 
PEC transport envelopel 


The same certification data is inserted in an XML file and added to 
the notification to allow for automatic checks (section 4.4). 

Parsing MUST be done on the XML part only. Additional parts MAY be 
included by the provider for provider-specific services. Regardless, 
the original message MUST NOT be included. The message MUST follow 
the format described in section 4.3. 


The message body MUST contain the reason for which the transmission 
could not be completed. 


Petrucci, et al. Informational [Page 27] 


RFC 6109 Certified Electronic Mail April 2011 


3.2.4. Virus-Induced Delivery Error PEC notification 


At the reception of a virus detection PEC notification from the 
receiving provider, the sender provider emits a non-delivery PEC 
notification to the sending user. 


The header for this notification contains the following fields: 


X-Ricevuta: errore-consegna 

X-VerificaSicurezza: errore 

Date: [date of notification emission] 

Subject: AVVISO DI MANCATA CONSEGNA PER VIRUS: [original 
subject] 

From: posta-certificata@[mail domain] 

To: [original sender] 

X-Riferimento-Message-1D: [msgid] 


The body contains a readable text part according to a model that 
relates the following data: 


Delivery error PEC notification due to virus 

On [date] at [time] ([time zone]), in the message "[subject]" 
addressed to "[recipient]" 

a security problem was detected [ID of content type detected 
by the anti-virus]. 

The message was not delivered. 

Message identifier: [PEC msgid of corresponding 

PEC transport envelope] 


All the information necessary for the construction of such a PEC 
notification can be obtained from the correlated virus-detected PEC 
notification. 


The same certification data is inserted in an XML file and added to 
the notification message to allow for automatic checks (section 4.4). 
Parsing MUST be done on the XML part only. Additional parts MAY be 
included by the provider for provider-specific services. The reason 
the transaction was not completed MUST be specified in the message, 
which MUST follow the format described in section 4.3. 
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3.3. Delivery Point 

3.3.1. Checks on Incoming Messages 
When a message arrives at the Delivery Point, the system verifies: 
o message type 
o whether or not a PEC notification has to be returned. 

3.3.2. Delivery PEC Notification 


A delivery PEC notification is issued only after a correct PEC 
transport envelope (sections 2.2.2 and 3.1.5) has been delivered to 
the recipient’s mailbox. 


In all other cases (e.g., PEC anomaly envelopes, PEC notifications), 
the delivery PEC notification is not issued. Regardless, the message 
received at the Delivery Point MUST be delivered to the recipient’s 
mailbox unchanged. 


This notification tells the user that his/her message has been 
successfully delivered to the specified recipient. It includes 
readable text that certifies the date and time of delivery, sender 
and receiver data, and the subject. It also contains an XML 
certification data file and other optional parts for functionalities 
offered by the provider. 


The following fields are inserted in the header: 


X-Ricevuta: avvenuta-consegna 

Date: [delivery date] 

Subject: CONSEGNA: [original subject] 
From: posta-certificata@[mail domain] 
To: [original sender] 
X-Riferimento-Message-ID: [msgid] 


The value of the "X-TipoRicevuta:" header field in the PEC transport 
envelope is derived from the original message, thus allowing the 
sender to determine the type of delivery PEC notification requested 
from the primary recipients of the original message. The 
notification MUST follow the format described in section 4.3. 


3.3.2.1. Delivery PEC Notification: Complete 


This is the default value for delivery PEC notifications. When no 
value for "X-TipoRicevuta:" is specified, or when it contains the 
value "completa" (complete), the system will require a complete 
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delivery PEC notification from addressees in the "To:" field, while a 
concise PEC notification (section 3.3.2.3) will be required from 
those in the "Cc:" field. The distinction between primary recipients 
and those in carbon copy is done through an analysis of the "To:" and 
"Cc:" fields. For PEC notifications sent on behalf of primary 
recipients, a complete copy of the original message along with any 
attachments is inserted in the notification. In case the system in 
charge of delivery is not able to determine the recipient type due to 
ambiguity problems in the "To:" and "Cc:" fields, delivery MUST be 
considered as if addressed to a primary recipient and include the 
complete copy of the original message. 


The notification body contains a readable text part that relates 
certification data according to the following model: 


Delivery PEC notification 


On [date] at [time] ([time zone]), the message "[subject]" 
originating from "[original sender]" and addressed to 
"[recipient]" 


was placed in the destination's mailbox. 
Message identifier: [PEC msgid of corresponding 
PEC transport envelope] 


The same certification data is inserted in an XML file and added to 
the notification (section 4.4), along with any other parts that MAY 
be inserted by the provider for provider-specific services. Parsing 
MUST be done on the XML part only. The delivery PEC notification 
MUST be issued on behalf of every recipient of the message, and MUST 
follow the format described in section 4.3. 


3.3.2.2. Delivery PEC Notification: Brief 


In order to decrease the amount of data flowing, it is possible for 
the sender to ask for a delivery PEC notification in "brief" format. 
The brief delivery PEC notification contains the original message and 
a ciphered hash value for each of its parts. The hash value SHOULD 
be calculated on base64 encoded parts. As specified in section 5.3, 
PEC messages MUST transit only on machines that belong to the PEC 
network and that MUST NOT alter the encoding of the message during 
its transition/processing. 


NOTE: Even though PEC uses these relaxed specifications, PEC 
interoperability tests between over 20 service providers have never 
revealed any problems. This is probably due to mail servers leaning 
more towards leaving the messages they receive intact without 
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applying any changes. But issues might arise if a server decides to 
modify encoded parts; for example, change the base64 line length, 
whose hash value calculated at the receiver’s end would then differ 
from that at the sender’s side. 


To be able to verify the transmitted contents it is necessary for the 
sender to keep the unaltered original copy of the part(s) to which 
the hash values refer. 
If the PEC transport envelope contains the header: 

X-TipoRicevuta: breve 
the Delivery Point emits a brief delivery PEC notification on behalf 
of the primary recipients, and a concise one (section 3.3.2.3) on 
behalf of carbon copy recipients. The value of the header field in 


the PEC transport envelope is derived from the original message. 


The notification body contains a readable text part according to a 
model that relates the following certification data: 


Brief delivery PEC notification 


On [date] at [time] ([time zone]), the message "[subject]" 
originating from "[original sender]" and addressed to 
"[recipient]" 


was placed in the destination's mailbox. 
Message identifier: [PEC msgid of corresponding 
PEC transport envelope] 


The same certification data is inserted in an XML file and added to 
the notification (section 4.4), along with other parts that MAY be 
included for specific provider-supplied services. Parsing MUST be 
done on the XML part only. The delivery PEC notification is issued 
on behalf of every recipient of the message, and MUST follow the 
format described in section 4.3. 


The MIME structure of the original message is unaltered as it is 
added to the notification, but each MIME part with a "name" parameter 
in the header field "Content-Type:" or a "filename" parameter in the 
header field "Content-Disposition:" MUST be substituted by a text 
file containing that MIME part's hash value. 


When the original message has an S/MIME format, it is necessary not 
to alter the integrity of the message structure. Verification of the 
S/MIME part in the original message takes place when the MIME type of 
the top-level entity (which coincides with the message itself) is 
checked. An S/MIME message MAY have the following MIME types (as per 
[SMIMEV3]) : 
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o multipart/signed 


Represents an original message signed by the sender using the 
structure described in [MIME-SECURE]. The message is made up of 
two MIME parts: the first is the message itself before the 
application of the sender’s signature, whereas the second contains 
Signature data. The second part (generally of type 
"application/pkcs7-signature" or "application/x-pkcs-signature") 
contains data added during the signing phase and MUST be left 
unchanged to avoid compromising the overall message structure; 


o "application/pkcs7-mime" or "application/x-pkcs7-mime" 


The message is composed of a sole CMS object within the MIME part. 
Given that attachments cannot be separated from the CMS object, 
the MIME part is left intact (i.e., it is not replaced by the hash 
value); therefore, the brief PEC notification is the same as the 
complete PEC notification. 


If the original message contains parts whose "Content-Type:" is 
"message/rfc822", i.e., contains an email message as attachment, the 
entire attached message is substituted with its corresponding hash 
value. 


Therefore, when emitting a brief delivery PEC notification, the 
provider MUST: 


1. identify and extract all the parts from the first MIME part of the 
multipart/signed S/MIME message; 


2. calculate the hash values of all the files attached by the sender 
to the original message; 


3. substitute originals with their hash values. 


In general, in the case of original messages in S/MIME format, the 
copy of the message inserted within the brief delivery PEC 
notification will have the following characteristics: 


o if the original message is signed, the S/MIME structure and 
signature-relative data will remain unchanged. The message will 
generate an error in a future signature integrity verification 
phase following the substitution of attachments with the 
corresponding hash values. 


o if the original message contains the "application/pkcs7-mime" or 


"application/x-pkcs7-mime" MIME type, attachments present in the 
message will not be substituted by their hash values, due to 
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impossibility of identification within a CMS structure. The 
content of the brief delivery PEC notification will coincide with 
that of a normal delivery PEC notification. 


The algorithm used for hash calculation is the [SHA1], calculated on 


the entire content of the part. To allow distinction between hash 
files and the files to which they refer, the suffix ".hash" is added 
to the original filename. The hash value is written in the file 


using a hexadecimal representation as a single sequence of 40 
characters. The MIME type of these attachments is set to 
"text/plain" to highlight their textual nature. 

3.3.2.3. Delivery PEC Notification: Concise 
If the PEC transport envelope contains the header: 

X-TipoRicevuta: sintetica 

the Delivery Point emits, both to primary and carbon copy recipients, 
a concise delivery PEC notification that does not contain the 


original message. 


The message body of the notification contains a readable text part 
according to a model that relates the following certification data: 


Concise delivery PEC notification 


On [date] at [time] ([time zone]), the message "[subject]" 
originating from "[original sender]" and addressed to 
"[recipient]" 


was placed in the destination's mailbox. 
Message identifier: [PEC msgid of corresponding 
PEC transport envelopel 


The same certification data is inserted within an XML file and added 
to the notification (section 4.4), along with additional parts that 
MAY be included for provider-specific services. Parsing MUST be done 
on the XML part only. The notification is sent to each one of the 
recipients to whom the message is delivered, and MUST follow the 
format described in section 4.3. 


The concise delivery PEC notification follows the same emission rules 


as the delivery PEC notification; added to it is only the XML file 
containing the certification data, not the original message. 
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Bed. 


Non-Delivery PEC Notification 


If an error occurs during the delivery of a correct PEC transport 
message, the system returns to the sender a non-delivery PEC 
notification that indicates the error condition. 


The header will contain the following fields: 


X-Ricevuta: errore-consegna 

Date: [date of notification emission] 

Subject: AVVISO DI MANCATA CONSEGNA: [original subject] 
From: posta-certificatal [mail domain] 

To: [original sender] 

X-Riferimento-Message-ID: [msgid] 


The notification body contains a readable text part according to a 
model that relates the following data: 


Non-delivery PEC notification 


On [date] at [time] ([time zone]), in the message "[subject]" 
originating from "[original sender]" and addressed to 
"[recipient]" 


an error was detected [brief error description]. 
The message was refused by the system. 

Message identifier: [PEC msgid of corresponding 
PEC transport envelope] 


The same certification data is inserted within an XML file and added 
to the notification in order to allow for automatic checks (section 
4.4). Parsing MUST be done on the XML part only. Additional parts 
MAY be included by the PEC provider for provider-specific services. 
The notification MUST follow the format described in section 4.3. 


Sala 


Sender and Receiver Belonging to the Same Domain 


PEC messages MUST be processed even if both sender and receiver (s) 
belong to the same PEC domain. 


3s 


Example: Complete Transaction between Two PEC Domains 


A correct transaction between two PEC domains goes through the 
following steps: 


o 


o 


The sending user sends an email to his provider’s Access Point; 


The Access Point runs all checks and emits a server-user 
acceptance PEC notification to the user; 
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4. 


4. 


o The Access Point creates a PEC transport envelope and forwards it 
to the Incoming Point of the receiving provider; 


o The receiver's Incoming Point verifies the PEC transport envelope 
and creates a server-server acceptance PEC notification to be sent 
to the sending provider; 


o The sender's Incoming Point verifies the validity of the server- 
server acceptance PEC notification and forwards it to the Delivery 
Point; 


o The sender's Delivery Point saves the server-server acceptance PEC 
notification in the provider's service mailbox; 


o The receiver's Incoming Point forwards the PEC transport envelope 
to the receiver's Delivery Point; 


o The receiver's Delivery Point verifies the contents of the PEC 
transport envelope and saves it in the recipient's mailbox; 


o The receiver's Delivery Point creates a delivery PEC notification 
and sends it to the sender’s Incoming Point; 


o The sender’s Incoming Point verifies the validity of the delivery 
PEC notification and forwards it to the sender’s Delivery Point; 


o The sender’s Delivery Point saves the delivery PEC notification in 
the sending user’s mailbox; 


o The receiving user has the message at his disposition. 


NOTE: Some of these steps might occur in parallel, thus the 
interaction might complete in a different order. 


Formats 
1. Temporal Reference 


For all operations carried out during message, notification, and log 
elaboration processes by the Access, Incoming, and Delivery Points, 
it is necessary to have an accurate temporal reference available. 

All events (generation of PEC notifications, transport envelopes, 
logs, etc.) that constitute the transaction of message elaboration at 
the Access, Incoming, and Delivery Points MUST employ a sole temporal 
value obtained from within the transaction itself. 
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Doing this renders the instant of message elaboration unambiguous 
within PEC logs, notifications, messages, etc., generated by the 
server. 


4.2. User Date/Time 


Temporal indications supplied by the service in readable format (text 
in PEC notifications, transport envelopes, etc.) are provided with 
reference to the legal time at the moment of the operation. 

Following is the specification using the syntax description notation 
defined in [ABNF]. 


date-fullyear = 4DIGIT 

date-month = 2DIGIT ; 01-12 

date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on 
; month/year 

time-hour = 2DIGIT ; 00-23 

time-minute = 2DIGIT ; 00-59 

time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second 
; rules 

time-offset = "(" ("+" / "-") time-hour ":" time-minute ")" 

partial-time = time-hour ":" time-minute ":" time-second 

full-date = date-mday "/" date-month "/" date-fullyear 

full-time = partial-time time-offset 


NOTE: For number of days in a month, leap year, and leap second 
restrictions see section 5.7 of [TIMESTAMP]. 


4.3. Format of a PEC Message Body 


This section describes the characteristics of the various components 
of PEC messages and notifications generated by a PEC system. If one 
of the message parts contains characters with values outside of the 
range 0-127 (7-bit ASCII), that part will have to be adequately 
encoded so that 7-bit transportation compatibility is guaranteed 
(e.g., quoted-printable, base64 as per [MIME1]). 


Before applying the signature, the message body has Content-Type: 
multipart/mixed. Each part is described in the sections below. The 
first part is the user readable text generated by the PEC systenm, 
while the second and third parts are interchangeable in order and 
contain the original message and the XML file for the certification 
data. 
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4.3.1. User Readable Text 


Character set: ISO-8859-1 (Latin-1) 
MIME type: text/plain or multipart/alternative 


April 2011 


The multipart/alternative MIME type MAY be used to add an HTML 


version of the body of system-generated messages. In this 
sub-parts MUST be present: one of type text/plain, the othe 
text/html. For the HTML part: 


o it MUST contain the same information as related in the t 


o it MUST NOT contain references to elements (e.g., images 


case, two 
E 


ext part; 


, sounds, 


font, style sheets), neither internal to the message (added MIME 
parts) nor external (e.g., hosted on the provider's server); 


o it MUST NOT have active content (e.g., JavaScript, VBscript, 


in, ActiveX). 
4.3.2. Original Message 


MIME type: message/rfc822 
Attachment name: postacert.eml 


4.3.3. Certification Data 
Character set: UTF-8 


MIME type: application/xml 
Attachment name: certdata.xml 


4.4. Certification Data Scheme 


Following is the DID relative to the [XML] file that contai 
certification data attached to PEC notifications. 


<!--Use the element "postacert" as root--> 


<!--"tipo" indicates the typology of the PEC message--> 
<!--The attribute "errore" can have the following values--> 
<!--"nessuno" = no error--> 

<!--"no-dest" (with type="errore-consegna") = --> 

<!-- wrong recipient 
<!--"no-dominio" (with type="errore-consegna") = --> 

<!-- wrong domain 
<!--"virus" (with type="errore-consegna") = virus--> 
<!--"virus" (with type="non-accettazione") = virus--> 
<!--"altro" = generic error--> 


<!ELEMENT postacert (intestazione, dati)> 
<!ATTLIST postacert 
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tipo (accettazione | 
non-accettazione | 
presa-in-carico | 
avvenuta-consegna 
posta-certificata | 
errore-consegna | 
preavviso-errore-consegna | 
rilevazione-virus) #REQUIRED 
errore (nessuno 
no-dest 
no-dominio | 
virus | 
altro) "nessuno"> 


<!--Header of the original message--> 

<!ELEMENT intestazione (mittente, 
destinatari+, 
risposte, 
oggetto?)> 


<!--Sender ("From:" field) of the original message--> 
<!ELEMENT mittente (#PCDATA) > 


<!--Complete list of recipients ("To:" and "Cc:" fields) -—-> 
<!--of the original message--> 
<!--"tipo" indicates the typology of the recipient--> 


<!ELEMENT destinatari (#PCDATA) > 
<!ATTLIST destinatari 
tipo (certificato | esterno) "certificato"> 


<!--Value of the "Reply-To:" field of the original message--> 
<!ELEMENT risposte (#PCDATA) > 
<!--Value of the "Subject:" field of the original message--> 
<!ELEMENT oggetto (#PCDATA) > 


<!--PEC message data--> 

<!ELEMENT dati (gestore-emittente, 
data, 
identificativo, 
msgid?, 
ricevuta?, 
consegna?, 
ricezione*, 
errore-esteso?)> 


<!--Descriptive string of the provider that certifies --> 


<!--the data--> 
<!ELEMENT gestore-emittente (#PCDATA) > 


Petrucci, et al. Informational [Page 38] 


RFC 6109 Certified Electronic Mail April 2011 


<!--Date/time of message elaboration--> 
<!--"zona" is the difference between local time and UTC in --> 
<!--"[+|-]hhmm" format--> 
<!ELEMENT data (giorno, ora)> 
<!ATTLIST data 
zona CDATA #REQUIRED> 


<!--Day in "dd/mm/yyyy" format--> 
<!ELEMENT giorno (#PCDATA) > 

<!--Local hour in "hh:mm:ss" format--> 
<!ELEMENT ora (#PCDATA) > 


<!--PEC msgid--> 
<!ELEMENT identificativo (#PCDATA) > 


<!--msgid of the original message before modifications--> 
<!ELEMENT msgid (#PCDATA) > 


<!--For PEC transport envelopes and delivery notifications--> 
<!--indicate the type of PEC notification requested by the--> 
<!--sender--> 
<!ELEMENT ricevuta EMPTY> 
<!ATTLIST ricevuta 
tipo (completa | 
breve 
sintetica ) #REQUIRED> 


<!--For delivery, non-delivery, virus-induced non-delivery, --> 
<!-- virus detection, and timeout PEC notifications--> 
<!--Recipient address to which delivery has been carried --> 
<!--out/tried--> 

<!ELEMENT consegna (#PCDATA)> 

<!--For server-server acceptance PEC notifications--> 
<!--recipients for whom it is the relative PEC notification--> 
<!ELEMENT ricezione (#PCDATA) > 


<!--In case of error--> 
<!--brief description of the error--> 
<!ELEMENT errore-esteso (#PCDATA) > 
4.5. PEC Providers Directory Scheme 
The PEC providers directory is created through a centralized LDAP 


server that contains the providers’ data and their corresponding PEC 
mail domains. 
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The following are the directory scheme’s attributes: 

- providerCertificateHash: hash of provider's certificate 
- providerCertificate: provider certificate 

— providerName: provider name 

- mailReceipt: provider reception email address 

- managedDomains: managed domains 

- LDIFLocationURL: provider LDIF record URL 

- providerUnit: secondary operating environment name 


The directory’s base root is "o=postacert" and the 
"DistinguishedName" of single records is of the type 
"<providerName=<name>,o=postacert>". Search within the directory is 
carried out mainly in case-sensitive mode using the 
"providerCertificateHash" attribute (during envelope signature 
verification phase) or the "managedDomains" attribute (during message 
acceptance phase). It is possible for the record of a single 
provider to contain multiple "providerCertificate" attributes with 
the related "providerCertificateHash" attributes in order to allow 
the handling of the renewal of expiring certificates. The provider 
MUST make sure to update its record with sufficient advance before 
the certificate expiration date, by adding a new certificate whose 
validity overlaps that of the previous one. 


The data of all PEC providers is encompassed in a [LDIF] file, which 
is available as an [HTTPS] object and can be found at the URL to 
which the ’LDIFLocationURL’ attribute in the "dn: o=postacert" record 
points (see section 4.5.6). To guarantee authenticity, that file 
MUST be signed by the provider for the operations regarding its PEC 
services using the method described for single providers. The file, 
the signature, and the X.509v3 certificate MUST be inserted in a 
PKCS#7 structure in binary ASN.1 DER format as a file with ".p7m" 
extension. The centralized [LDAP] system downloads that file on a 
daily basis and, after suitable verifications of the signature, 
applies it to the provider's record. 


Through the [LDIF] file, single providers MUST keep a copy of the 
directory locally, updated on a daily basis, in order to improve 
system performance by avoiding continuous request dispatches to the 
central system for every message elaboration phase. 
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If secondary environments are present, the [LDIF] file indicated in 
the main environment’s record MUST relate the contents of all the 
provider-relevant records. 


NOTE: This specification uses an unregistered LDAP DN name space 
that may lead to conflict with other registered or 
unregistered names. 


4.5.1. providerCertificateHash Attribute 


The ’providerCertificateHash’ attribute is a hexadecimal 
representation of the hash in SHAl format of the X.509v3 certificate 
used by the provider for PEC notifications and envelope signatures. 


( 1.3.6.1.4.1.16572.2.2.1 NAME 'providerCertificateHash' 
DESC “Hash SHAl of X.509 certificate in hexadecimal format’ 
EQUALITY caselgnorelA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in 
[LDAP-SYNTAXES]. 


4.5.2. providerCertificate Attribute 
The ’providerCertificate’ attribute holds a set of certificate(s) 
used by the provider to sign PEC notifications and transport 
envelopes. 
( 1.3.6.1.4.1.16572.2.2.2 NAME ‘providerCertificate’ 
DESC 'X.509 certificate in ASN.1 DER binary format’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 


The Certificate syntax ( 1.3.6.1.4.1.1466.115.121.1.8 ) is defined in 
[RFC4523]. 


As required by this attribute type’s syntax, values of this attribute 
are requested and transferred using the attribute description 
"providerCertificate;binary" [RFC4522]. 

4.5.3. providerName Attribute 


The ’providerName’ attribute contains the name of the PEC provider. 
All records MUST contain their provider’s name in this attribute. 
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( 1.3.6.1.4.1.16572.2.2.3 NAME ’providerName’ 
DESC "PEC provider name’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is 
defined in [LDAP-SYNTAXES]. 


4.5.4. mailReceipt Attribute 


The ’mailReceipt’ attribute contains the provider’s email address 
within the provider to which server-server acceptance and virus 
detection PEC notifications are sent. This address is a limited 
version of the addr-spec construct described in [EMAIL] (without 
angle brackets); it only permits the dot-atom-text form on both the 
left- and right-hand sides of the "@", and does not have internal 
CFWS. 


( 1.3.6.1.4.1.16572.2.2.4 NAME ’mailReceipt’ 
DESC ’E-mail address of the service mailbox’ 
EQUALITY caseIgnoreIA5Match 
SUBSTR caselgnorelA5SubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
SINGLE-VALUE ) 


The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in 
[LDAP-SYNTAXES]. 


4.5.5. managedDomains Attribute 
The ’managedDomains’ attribute holds a set of domains [SMTP] that are 


handled by a PEC provider. Domains are limited to dot-atom form 
([REC1034], [EMAIL]). 


( 1.3.6.1.4.1.16572.2.2.5 NAME ’managedDomains’ 
DESC "Domains handled by the PEC provider’ 
EQUALITY caseIgnoreIA5Match 
SUBSTR caselgnorelA5SubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


The IA5String ( 1.3.6.1.4.1.1466.115.121.26 ) syntax is defined in 
[LDAP-SYNTAXES]. 


The ’managedDomains’ attribute holds a set of domains [SMTP] that are 


handled by a PEC provider. Domains are limited to dot-atom form 
([RFEC1034], [EMAIL]). 
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4.5.6. LDIFLocationURL Attribute 


The 'LDIFLocationURL” attribute contains an [HTTPS] URL that points 
to the location of the [LDIF] file defining the provider’s record. 
When the attribute is present in the record "dn: o=postacert", then 
it contains the definition of the entire directory in [LDIF] format. 
The LDIF file will have a MIME type of application/pkcs7-mime, with 
the parameter smime-type/signed-data. [SMIMEV3] The LDIF file is 
encoded using the UTF-8 character set. 


Secondary environment records MUST NOT contain the ’LDIFLocationURL’ 
attribute which is obtained from the main environment’s attributes 
for all records connected to the provider. 


( 1.3.6.1.4.1.16572.2.2.6 NAME ’LDIFLocationURL’ 
DESC "URL of the LDIF file that defines the entry’ 
EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is 
defined in [LDAP-SYNTAXES]. 


4.5.7. providerUnit Attribute 


The ’providerUnit’ attribute contains the name of secondary operating 
environments -- an attribute not present for the main environment. 

It is possible for the provider to define several distinct records, 
each indicating a single, different, secondary operating environment, 
for which it is possible to declare specific attributes that are, if 
need be, distinct from those relative to the main and other 
environments. 


The "DistinguishedName" of the records relative to the secondary 
operating environments are of the type 
"<providerUnits=<environment>, providerName=<name>,o=postacert>". 
Every provider MUST have a record associated to its own main 
environment, distinguishable for the absence of the "providerUnit" 
attribute within the record and the DistinguishedName. 


( 1.3.6.1.4.1.16572.2.2.7 NAME ’providerUnit’ 
DESC ‘Name of the secondary operative environment’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 
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The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is 
defined in [LDAP-SYNTAXES]. 


4.5. 


LDIFLocationURLObject Object Class 


The schema definition of the 'LDIFLocationURLObject” object class: 


( 


4.5. 


1.3.6.1.4.1.16572.2.1.1 NAME ’LDIFLocationURLObject’ 
SUP top AUXILIARY 
MAY ( LDIFLocationURL ) ) 


Provider Object Class 


The schema definition of the 'provider” object class: 


( 


4.5.10. 


1.3.6.1.4.1.16572.2.1.2 NAME ’provider’ 
SUP top STRUCTURAL 
MUST ( providerCertificateHash 


providerCertificate 
providerName 
mailReceipt 
managedDomains ) 


MAY ( description 


LDIFLocationURL 
providerUnit ) 


LDIF File Example 


The following LDIF file represents an example of a providers’ 
directory, containing a base root and two fictitious providers. The 
inserted certificates are two self-signed certificates used for 
example purposes only: 


dn: o=postacert 

objectclass: top 

objectclass: organization 

objectClass: LDIFLocationURLObject 

o: postacert 

LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m 

description: Base root for the PEC providers directory 

dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert 

objectclass: top 

objectclass: provider 

providerName: Anonymous Certified Mail S.p.A. 

providerCertificateHash: 
TETAEF1059AE0F454F2643A95F69EC3556009239 

providerCertificate;binary:: 
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MIIDBjCCAm+tgAwIBAgIBADANBgkqghkiG9w0BAQ0FADBmMOswCQYDVOOGEw 
JIVDEPMCcGALUEChMgQW5vbm1t YSBOb3NOYSBDZXJ0aWZpY2FO0YSBTLnAu 
QS4xLDAgBgkqghkiG9w0BCOEWHXBvc3RhLWN1cnRpZmljYXRhOGFucG9jZX 
J0Lm10MB4XDTAyMT IwOTE3MjQxNVOXDTAZMT IwOTE3MjQxNVowZ jELMAKG 
A1UEBhHMCSVQOxKTAnBgNVBAOTIEFub2 5pbWEgUG9zdGEgQ2VydGlmaWNhdG 
EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS13ZXJ0aWZpY2F0OYUBRh 
bnBvY2VydC5pdDCBnzANBgkgqhkiG9w0BAOQEFAAOB jJOAWgYkCgYEAr8J+qK 
KdxV9LZDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUKONcbrvlQyXZNNt SMC 
2uL09HDyx8agjgzZWdhypnehguiSK3busha15RSpMGhigxmz2b0Hh0G73Gf 
alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5lalhWxzy34XcCAwHAAaOB 
wzCBwDAdBgNVHO4EF gQUN81C0znQWESOxspZ/aBzsaGvRZMwgZAGA1UdIw 
SBiDCBhYAUN81C0znQWESOxspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT 
Ak1UMSkwJwYDVOOKEyBBbm9uaW1hIFBvc3RhIEN1cnReZml3jYXRhIFMucc 
5SBLIESMCOGCSQGS Ib3DQEJARYdcG9zdGEt Y2VydGlmaWNhdGFAYW5wb2N1 
cnQuaXSCAQAwDAYDVROTBAUWAWEB / zANBgkqhkiG9w0BAQQFAAOBgQA5 8B 
Zt+qlqSKpuffzTBpMtbeFkDIxMqMatycnxdMNvcWgCm1lA9ZiFJsvqYhDDqA 
XxfH3krzXuSZkYq6wiQCsLp0aYVy400CIwbO0unhrvsxh3vsG5CgN76JzZ9 
5Z/10CENhLfqf1VH2NSS8TaYCCi/VO7W1O01KkcA2V1x10P7McSUw== 

mailReceipt: ssacceptance@postalser.example.com 
LDIFLocationURL: https://anpocert.example.com/anpocert.ldif.p7m 

managedDomains: mail.anpocert.example.com 

managedDomains: cert.company.example.com 

managedDomains: costmec.example.com 

description: Certified mail services for companies 


dn: providerName=Postal Services S.p.A,o=postacert 
objectclass: top 
objectclass: provider 
providerName: Postal Services S.p.A 
providerCertificateHash: 
e00£fdd9d88be0e2cc766b893315caf93d5701a46a 
providerCertificate;binary:: 
MIIDHjCCAcoegAwIBAgIBADANBgkqghkiG9w0BAQ0FADBuMOswCQYDVOOGEw 
JIVDEFMBOGA1UECAMWU2Vydml 6aSBOb3NOYWxpIFMuci5sLjJEPMAOGA1UE 
CxMGRC5DLkMuMS0wKwYJKoZIhvcNAOKBFh5wb3N0YS1jZXJ0aWZpY2FOYU 
BzZXJwb3NOYWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjAS5MTczMjE2 
WjBuMQswCQYDVOOGEwJJVDE£fMBOGA1UEChKMWU2Vydml6aSB0b3N0YWxpIF 
Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQOKBFh5wb3N0 
YS1jZXJ0aWZpY2F0YUBzZXJwb3NOYWwuaXQwgZ8wDOYJKoZIhvcNAQEBBO 
ADgYOAMIGJAOGBAKoc7n6zA+SO8NATMcf£J+U2a0DEsrj/cObG3QAN6Sr+1 
ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsqOPIEaYZhYRGjhbcuJ9H/ZdtWdX 
xCWEWN4mwFzlsASogsh5JegS8db3A1JWkvh09EUfaCYk8YMAKXYdCtLD9s 
9tCYZeTE2ut 9YAGMBAAG jgcswgcgwHOYDVROOBBYEFHPw/VJIoIM3VYhuHa 
eAwpPF51eMMIGYBgNVHSMEgZAwgY 2AFHPw/VJIOIM3VYhuHaeAwpPF51leM 
oXKkcDBuMQswCOQYDVQQGEWJJVDEfMBOGALUECHMWU2Vydm1 6aSBOb3N0YW 
xpIFMuci5sLjEPMAOGA1UECXMGRC5DLkMuMSOwKwYJKoZIhvcNAQkBFh5w 
b3N0YS13ZXJ0aWZpY2F0OYUBZZXJIwb3N0YWwuaXSCAQAwWDAYDVROTBAUwWAw 
EB/zANBgkgqhkiG9w0BAQOFAAOBgOApgeXvmOyE jwhMrXezPAXELMZwv4qq 
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r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNOMNxYFVJqdWoLh8qExsTLXn 
sKycSnHbC fuphrkKvX jQvR2da75U4zGSkroiyvJ2s 9TtiCcT310tI jmvrFb 
aSBiyzj+za7foFUCOmxCLtDaA== 
mailReceipt: takecharge@postalser.example.com 
LDIFLocationURL: https://postalser.example.com/ldif.txt.p7m 
managedDomains: postal-services.example.com 
managedDomains: receivedmail.example.com 
description: Certified mail services for the public 


The following LDIF file represents an example of a PEC providers’ 
directory, containing a base root and two fictitious providers, the 
first of which handles a secondary environment as well. The 
certificates inserted are two self-signed certificates used for 
example purposes only: 


dn: o=postacert 

objectclass: top 

objectclass: organization 

objectClass: LDIFLocationURLObject 

o: postacert 

LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m 
description: Base root for the PEC providers directory 


dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert 
objectclass: top 

objectclass: provider 

providerName: Anonymous Certified Mail S.p.A. 


providerCertificateHash: 
TETAEF1059AE0F454F2643A95F69EC3556009239 
providerCertificate;binary:: 
MIIDBjCCAm+tgAwIBAgIBADANBgkqghkiG9w0BAQO0FADBmMOswCQYDVOOGEw 
JIVDEPMCcGALUEChMgQW5vbm1t YSBOb3NOYSBDZXJ0aWZpY2FO0YSBTLnAu 
OS4xLDAqBgkqhkiG9Iw0BCOEWHXBvc3RhLWN1cnRpZml3jYXRh0GFucG93ZX 
J0Lm10MB4XDTAyMT IwOTE3MjQxNVOXDTAZMT IwOTE3MjQxNVowZ jELMAKG 
A1LUEBhHMCSVQOxKTAnBgNVBAOTIEFub2 5pbWEgUG9zdGEgQ2VydGlmaWNhdG 
EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS13ZXJ0aWZpY2F0OYUBRh 
bnBvY2VydC5pdDCBnzANBgkgqhkiG9w0BAOQEFAAOB jJOAWgGYkCgYEAr8J+qK 
KdxV9LZDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUKONcbrvlQyXZNNt SMC 
2uL09HDyx8ag  jgZWdhypnehguiSK3bushal 5RSpMGhiqxmz2b0HhOG73Gf£ 
alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5lalhWxzy34XcCAwHAAaOB 
wzCBwDAdBgNVHO4EF gQUN81CO0znQWESOxspZ/aBzsaGvRZMwgZAGA1UdIw 
SBiDCBhYAUN81C0znQWESOxspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT 
AKk1UMSkwJwYDVOOKEyBBbm9uaWlhIFBvc3RhIENlcnRpZmljYXRhIFMucC 
5BLjEsMCoGCSqGSIb3DOEJARYdcG9zdGEtY2VydGlmaWNhAGFAYW5wb2N1 
cnQuaXSCAQAWDAYDVROTBAUwWAwEB/zANBgkqhkiG9w0BAQOFAAOBgOA58B 
Z+aq1lgSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCmlA9ZiFIJsvgYhDDgA 
XxfH3krzXuSZkYq6wiQCsLp0aYVy400CIwbO0unhrvsxh3vsG5CgN76JzZ9 
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5Z/10CENhLfqf1VH2NSS8TaYCCi/VOTW101KkcA2V1x10P7McSUw== 

mailReceipt: notifications@anpocert.it.example 
LDIFLocationURL: http://anpocert.example.com/anpocert.ldif.p7m 

managedDomains: mail.anpocert.example.com 

managedDomains: cert.company.example.com 

managedDomains: costmec.example.com 

description: Certified mail services for companies 

dn: providerUnit=Secondary Environment, providerName=Anonymous 
Certified Mail S.p.A.,o=postacert 

objectclass: top 

objectclass: provider 

providerName: Certified Mail S.p.A. 

providerUnit: Secondary Environment 

providerCertificateHash: 
TETAEF1059AE0F454F2643A95F69EC3556009239 

providerCertificate;binary:: 
MIIDBjCCAm+tgAwIBAgIBADANBgkghkiG9w0BAQO0FADBmMOswCQYDVOOGEw 
JIVDEPMCcGALUEChMgQW5vbm1t YSBOb3NOYSBDZXJ0aWZpY2FO0YSBTLnAu 
QS4xLDAgBgkqghkiG9w0BCOEWHXBvc3RhLWN1cnRpZmljYXRhOGFucG9jZX 
J0Lm10MB4XDTAyMT IwOTE3MjQxNVOXDTAZMT IwOTE3MjQxNVowZ jELMAKG 
A1UEBhHMCSVQOxXKTAnBgNVBAOTIEFub2 5pbWEgUG9zdGEgQ2VydGlmaWNhdG 
EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS13ZXJ0aWZpY2F0OYUBRh 
bnBvY2VydC5pdDCBnzANBgkghkiG9w0BAOQEFAAOB jJOAwWgYkCgYEAr8J+qK 
KdxV9LZDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUKONcbrvlQyXZNNt SMC 
2uL09HDyx8ag  jgZWdhypnehguiSK3bushal 5RSpMGhiqxmz2b0HhOG73Gf£ 
alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5lalhWxzy34XcCAwHAAaOB 
wzCBwDAdBgNVHO4EF gGQUN81CO0znQWESOxspZ/aBzsaGvRZMwgZAGA1UdIw 
SBiDCBhYAUN81C0znQWEs0xspZ/aBzsaGvRZOhagRoMGYxCzAJBgNVBAYT 
Ak1UMSkwJwYDVOQOKEyBBbm9uaWlhIFBvc3RhIEN]lcnRpZmljYXRhIFMucC 
5BLJESMCOGCSQGS Ib3DQEJARYdcG9zdGEt Y2VydGlmaWNhdGFAYW5wb2N1 
cnQuaXSCAQAwDAYDVROTBAUWAWEB/ zANBgkqhkiG9w0OBAQQFAAOBgQA5 8B 
Zt+qlqSKpuffzTBpMtbeFkDIxMqMatycnxdMNvcWgCm1lA9ZiFIJsvqYhDDgA 
XxfH3krzXuSZkYq6wWwiQCsLp0aYVy400CIwbO0unhrvsxh3vsG5CgN76JzZ9 
5Z/10CFNhLfqf1VH2NSS8TaYCCi/VOTW1Q1KkcA2V1x1Q0P7McsUw== 

mailReceipt: notifications@secondary.anpocert.example.com 

managedDomains: management .anpocert .example.com 

managedDomains: personnel.anpocert.example.com 

description: Corporate internal services 

dn: providerName=Postal Services S.r.l.,o=postacert 
objectclass: top 

objectclass: provider 

providerName: Postal Services S.r.l. 

providerCertificateHash: 
e00fdd9188be0e2cc766b893315caf93d570l1la6a 

providerCertificate;binary:: 
MIIDHjCCAcoegAwIBAgIBADANBgkqghkiG9w0BAQ0FADBuMOswCQYDVOOGEw 
JIVDEFMBOGA1UECAMWU2Vydml 6aSBOb3NOYWxpIFMuci5sLjJEPMAOGA1UE 
CxMGRC5DLkMuMS0wKwYJKoZIhvcNAOKBFh5wb3N0YS1jZXJ0aWZpY2FOYU 
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BzZXJwb3NOYWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjAS5MTczMjE2 
WjBuMQswCQYDVOOGEwJJVDEf£fMBOGA1UEChKMWU2Vydml6aSB0QOb3N0YWxpIF 
Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQOKBFh5wb3N0 
YS1jZXJ0aWZpY2F0YUBzZXJwb3NOYWwuaXQwgZ8wDOYJKoZIhvcNAQEBBO 
ADgYOAMIGJAOGBAKoc7n6zA+SO8NATMcf£J+U2a0DEsrj/cObG3QAN6Sr+1 
ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsqOPIEaYZhYRGjhbcuJ9H/ZdtWdx 
xCWEWN4mwFzlsASogsh5JegS8db3A1JWkvh09EUfaCYk8YMAKXYdCtLD9s 
9tCYZeTE2ut 9AgMBAAGjgcswgcgwHOYDVR0OBBYEFHPw7VJIoIM3VYhuHa 
eAwpPF5leMMIGYBgNVHSMEgzZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM 
oXKkcDBuMOswCOYDVOOGEwWJJVDEfMBOGA1UECAMWU2Vydml 6aSBOb3N0YW 
xpIFMuci5sLjEPMAOGA1UECXMGRC5DLkMuMSOwKwYJKoZIhvcNAQkBFh5w 
b3N0YS13ZXJ0aWZpY2FOYUBZZXIwb3N0YWwuaXSCAQAwWDAYDVROTBAUwWAw 
EB/zANBgkgqhkiG9w0BAQOFAAOBgOApgeXvmOyE jwhMrXezPAXELMZwv4qq 
r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNOMNxYFVJqdWoLh8qExsTLXn 
sKycPSnHbC fuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT310tIijmvrF 
baSBiyzj+za7foFUCOmxCLtDaA== 

mailReceipt: ssacceptance@postalser.example.com 

LDIFLocationURL: http://postalser.example.com/ldif.txt.p7m 

managedDomains: postal-services.example.com 

managedDomains: receivedmail.example.com 

description: Certified mail services for the public 


5. Security-Related Aspects 
5.1. Digital Signature 


It is recommended that a dedicated hardware module be used to handle 

private key and signature operations, the specifications of which are 
outside the scope of this document. It’s up to the PEC providers to 

conform to security requisites expected for the service. 


5.2. Authentication 


User access to PEC services through the Access Point MUST be allowed 
only upon successful user authentication on the system. 


For example, authentication might use user-ID and password, or, if 
available and considered necessary for the type of service provided, 
an electronic ID card or the national services card. Choice of 
authentication method is left to the better judgment of the service 
provider. Authentication is necessary to guarantee as much as 
possible that the message is sent by a PEC user whose identification 
data is congruent with the specified sender, so as to avoid 
falsification of the latter. 
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DE 
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57 


da 


4. 
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Secure Interaction 


To guarantee that the original message remains unaltered during 
transaction, envelopment and signature are applied on outgoing 
messages at the Access Point, and subsequent verification of incoming 
messages is done at the Incoming Point. 


All communications within the PEC network MUST use secure channels. 
Integrity and confidentiality of connections between PEC provider and 
user MUST be guaranteed through the use of secure protocols, such as 
those based on [TLS] and those that create a secure transport channel 
on which non-secure protocols can transmit (e.g., IPsec). 


The interaction between providers MUST take place using SMTP on 
[TLS], as per [SMTP-TLS]. The Incoming Point MUST provide and 
announce its support for the STARTTLS extension, as well as accept 
both unencrypted connections (for ordinary mail) and protected ones. 
To guarantee complete traceability in the flow of PEC messages, these 
MUST NOT transit on systems external to the PEC network. When 
exchanging messages between different providers, all transactions 
MUST take place between machines that belong to the PEC network or 
are directly managed by the provider. An "MX" type record MAY be 
associated to each PEC domain defined within the system for name 
resolution, in which case secondary reception systems specified in 
that record MUST be under direct control of the provider. All in 
conformance with [SMTP]. 


Virus 


Another important security aspect that concerns the PEC system, is 
related to the technical and functional architecture that MUST block 
the presence of viruses from endangering the security of all handled 
messages. It is therefore REQUIRED to have installations and 
continuous updates of anti-virus systems that hinder infections as 
much as possible without intervening on the content of the certified 
mail, in compliance with what has been discussed thus far. 


S/MIME Certificate 


In this document the S/MIME certificate profile is defined for use in 
the certification of PEC messages done by the providers. The 
proposed profile of the S/MIME certificate is based on the IETF 
standards [SMIMECERT] and [CRL], which in turn are based on the 
standard ISO/IEC 9594-8:2001. 
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5.5.1. Provider-Related Information (Subject) 

The information related to the PEC provider holder of the certificate 
MUST be inserted in the Subject field (Subject DN). More precisely, 
the Subject DN MUST contain the PEC provider’s name as it is in the 
"providerName" attribute published in the PEC providers directory 
(section 4.5), but the Subject DN does not have to match the Provider 
entry DN in the LDIF. The providerName MUST be present in the 
CommonName or OrganizationName attributes of the "Subject:" field in 
the certificate. 
Certificates MUST contain an Internet mail address, which MUST have a 
value in the subjectAltName extension, and SHOULD NOT be present in 
the Subject Distinguished Name. 
Valid subjectDN are: 

C=IT, O=AcmePEC S.p.A, CN=Posta Certificata 

C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata 


Valorization of other attributes in the Subject DN, if present, MUST 
be done in compliance with [CRL]. 


5.5.2. Certificate Extensions 
Extensions that MUST be present in the S/MIME certificate are: 
o Key Usage 
o Authority Key Identifier 
o Subject Key Identifier 
o Subject Alternative Name 


The Basic Constraints extension (Object ID:2.5.29.19) MUST NOT be 
present. 


The valorization of the above listed extensions for the described 
profile follows. 


The Key Usage extension (Object ID: 2.5.29.15) MUST have the 
digitalSignature bit (bit 0) activated and MUST be marked as 
critical. The extension MAY contain other active bits corresponding 
to different Key Usage, as long as that doesn’t contrast with the 
indications in [CRL]. 
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The Authority Key Identifier (Object ID: 2.5.29.35) MUST contain at 
least the keyIdentifier field and MUST NOT be marked as critical. 


The Subject Key Identifier extension (Object ID: 2.5.29.14) MUST 
contain at least the keyIdentifier field and MUST NOT be marked as 
critical. 


The Subject Alternative Name (Object ID: 2.5.29.17) MUST contain at 
least the rfc822Name field and MUST NOT be marked as critical. 


Adding other extensions that have not been described in this document 
is to be considered OPTIONAL, as long as it remains compliant with 
[CRL]; such added extensions MUST NOT be marked as critical. 


5.5.3. Example 


Following is an example of an S/MIME certificate compliant with the 
minimal requisites described in this profile. Values used are of 
fictitious providers generated for example purposes only. 


5.5.3.1. General-Use Certificate in Annotated Version 


An asterisk near the label of an extension means that such an 
extension has been marked as critical. 


VERSION: 3 
SERIAL: 11226 (0x2bda) 
INNER SIGNATURE: 
ALG. ID: id-shal-with-rsa-encryption 
PARAMETER: 0 
ISSUER: 
Country Name: IT 
Organization Name: Certifier 1 
Organizational Unit Name: Certification Service Provider 
Common Name: Certifier S.p.A. 
VALIDITY: 
Not Before: Oct 5, 04 09:04:23 GMT 
Not After: Oct 5, 05 09:04:23 GMT 
SUBJECT: 
Country Name: IT 
Organization Name: AcmePEC S.p.A. 
Common Name: Certified Mail 
PUBLIC KEY: (key size is 1024 bits) 
ALGORITHM: 
ALG. ID: id-rsa-encryption 
PARAMETER: 0 
MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be 
7£691945 89d01569 ca0d555b 5c33d7e9 
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d15££128 6792def5 b3f884e6 54b326db 
cf 


EXPONENT: 0x010001 

EXTENSIONS: 

Subject Alt Name: 

RFC Name: posta-certificatalacmepec.it 

Key Usage*: Digital Signature 

Authority Key Identifier: 0x12345678 aaaaaaaa bbbbbbbb 


ceccccce dddddddd 


Subject Key Identifier: 0x3afae080 6453527a 3e5709d8 49a941a8 


a3a70ael 


SIGNATURE: 


Lis 


0 30 
4 30 
8 AO 


10 


13 
EY 
19 


30 


32 
34 
36 
38 
43 


47 
49 
51 
56 


77 


Petrucci, 


30 


31 


ALG. 


ID: id-shal-with-rsa-encryption 


PARAMETER: 0 
VALUE: 0x874b4d25 70a46180 c9770a85 fe7923ce 


b22d2955 2f3af207 142b2aba 643aaa61 


d8fd10b4 c9e00ebc c089£7a3 549a1907 
ff885220 ce796328 bOf8ecac 86ffblcc 


General-Use Certificate in Dump ASN.1 


794: 
514: 
3 
lt 


2 


13% 


22: 


SEQUENCE { 


SEQUENCE { 
[01 4 
INTEGER 2 
} 
INTEGER 11226 
SEQUENCE { 
OBJECT IDENTIFIER 
shalwithRSAEncryption (1 2 840 113549 1 1 5) 
NULL 


SEQUENCE { 

SET { 
SEQUENCE { 
OBJECT IDENTIFIER countryName (2 5 4 6) 
PrintableString ‘IT’ 


SET { 

SEQUENCE { 
OBJECT IDENTIFIER organizationName (2 5 4 10) 
PrintableString ’Certificatore 1’ 


SET { 
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79 30 20: SEQUENCE { 
81 06 3 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 
86 13 13% PrintableString ’Certification Service Provider’ 
} 
; } 
101 341 32 SET { 
103 30 30: SEQUENCE ( 
105 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 


dio: AB 23% PrintableString 'Certificatore S.p.A.” 


135 30 30: SEQUENCE { 

137 17 13: UTCTime ’0410050904232’ 

152 17 13: UTCTime 0510050904232” 
: } 

167 30 66: SEQUENCE { 


169 31 11: SET { 
E7130. DQ: SEQUENCE { 
L35 "0:65, «St OBJECT IDENTIFIER countryName (2 5 4 6) 


LIS 13 » 32% PrintableString ‘IT’ 
: } 


182 31 23: SET { 


184 30 21: SEQUENCE ( 
186 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 


T91 T3 as PrintableString 'AcmePEC S.p.A.” 
: } 


207 31 26: SET { 


209 30 24: SEQUENCE { 
211 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 


216 13 17: PrintableString ’Posta Certificata’ 
: } 
} 
>} 
235 30 159: SEQUENCE { 


238: 301 13% SEQUENCE { 
240 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 
d'a) 


251 05 0: NULL 
E ) 
253 03 141: BIT STRING 0 unused bits 
: 30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B 
AC 3F 1B 29 B5 BE 7F 69 19 45 89 DO 15 69 CA OD 
55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD 
CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85 
4D 74 76 DD OB B5 78 4F 1E 84 DD B4 86 7F 96 DF 
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5E 7B AF OE CE EA 12 57 OB DF 9B 63 67 4D F9 37 

B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D 

85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8 
[ Another 12 bytes skipped ] 


; } 
397 A3 123: [3] { 
399 30 121: SEQUENCE { 


401 30 39: SEQUENCE { 
403 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 


408 04 32: OCTET STRING 
: 30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66 
69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74 
Š } 
442 30 


14: SEQUENCE { 

444 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 
449 01 1 BOOLEAN TRUE 
452 04 4 OCTET STRING 

: 03 02 07 80 

: } 
458 30 31: SEQUENCE ( 
460 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 
465 04 24: OCTET STRING 

: 30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC 

CC CC DD DD DD DD 

: } 
491 30 29: SEQUENCE ( 
493 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 
498 04 22: OCTET STRING 

A 04 14 3A FA EO 80 64 53 52 7A 3E 57 09 D8 49 A9 


41 A8 A3 A7 OA El 
} 
} 
} 
: } 
522 30 13: SEQUENCE { 
524 06 9: OBJECT IDENTIFIER 
: shalwithRSAEncryption (1 2 840 113549 1 1 5) 
535 05 0: NULL 
: } 
537 03 257: BIT STRING 0 unused bits 
: 87 4B 4D 25 70 A4 61 80 C9 77 OA 85 FE 79 23 CE 
B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61 
1F FO E7 3F C4 E6 13 E2 09 3D FO El 83 AO CO F2 
C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91 
51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50 
9F C6 42 D4 7C 38 Bl DD 88 CD FC E8 C3 12 C3 62 
64 OF 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70 
E2 D3 OF 00 BO FD 92 11 6C 55 45 48 F5 64 ED 98 
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[ Another 128 bytes skipped ] 
} 


5.6. PEC Providers Directory 


The contents of the PEC providers directory MUST be queried via 
[HTTP] on a Secure Socket Layer (SSL), as described in [TLS], 
exclusively by licensed providers that have the necessary user 
certificates; this access modality guarantees authenticity, 
integrity, and confidentiality of data. Each provider downloads the 
LDIF file through an [HTTPS] session, which is authenticated by 
checking the X.509 certificate issued by a certification authority. 


6. PEC System Client Technical and Functional Prerequisites 


This section lists the prerequisites that must be respected by a 
client in order to guarantee the minimal operative functionalities to 
the user of a general PEC system: 


o handling of Access and Delivery Points through secure channels; 


o handling of user authentication in message dispatch and reception 
which make use of standard protocols, such as [IMAP], [POP3], and 
[HTTP]; 


o support for MIME format according to [MIME1] and [MIME5]; 
o support for "ISO-8859-1 (Latin-1)" character set; 


o support for S/MIME v3 standard, as in [SMIMEV3], for verification 
of signatures applied to PEC envelopes and notifications. 


7. Security Considerations 


All security considerations from [CMS] and [SMIMEV3] apply to 
applications that use procedures described in this document. 


The centralized LDAP server is a critical point for the security of 
the whole PEC system. An attack could compromise the whole PEC 
system. PEC providers that periodically download the LDIF file 
SHOULD use the best security technology to protect it from local 
attacks. A PEC provider could be compromised if an attacker changed 
a certificate or modified the list of domains associated to it in the 
LDIF file that was copied to the PEC provider system. 
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When verifying the validity of the signature of a message, the 
recipient system SHOULD verify that the certificate included in the 
[CMS] message is present in the LDIF file (section 4.5) and that the 
domain extracted by the [EMAIL] "From:" header is listed in the 
managedDomains attribute associated to said certificate. 


8. IANA Considerations 


8.1. Registration of PEC Message Header Fields 


This document defines new header fields used in the messages that 
transit in the PEC network. As specified and required by 
[HEADERS-IANA], this document registers new header fields as 
Provisional Message Header Fields as follows. 


8.1.1. Header Field: X-Riferimento-Message- ID: 
Applicable protocol: mail [EMAIL] 
Status: provisional 
Author/Change controller: 
Claudio Petrucci 
DigitPA 
Viale Carlo Marx 31/49 
00137 Roma 
Italy 
EMail: PETRUCCI@digitpa.gov.it 
Specification document: this document, section 2.2.1, Appendix A. 
8.1.2. Header Field: X-Ricevuta: 
Applicable protocol: mail [EMAIL] 
Status: provisional 
Author/Change controller: 
Claudio Petrucci 
DigitPA 
Viale Carlo Marx 31/49 
00137 Roma 


Italy 
EMail: PETRUCCI@digitpa.gov.it 
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Specification document: this document, sections 2.1.1 
Ble By ALO Lol 3a 
3.3.2, 3.3.3, Appendix A. 


8.1.3. Header Field: X-VerificaSicurezza: 
Applicable protocol: mail [EMAIL] 
Status: provisional 
Author/Change controller: 

Claudio Petrucci 

DigitPA 

Viale Carlo Marx 31/49 

00137 Roma 

Italy 

EMail: PETRUCCI@digitpa.gov.it 


Specification document: this document, sections 2.1.1.1.3, 3.1.3, 
3.2.4, Appendix A. 


8.1.4. Header Field: X-Trasporto: 
Applicable protocol: mail [EMAIL] 
Status: provisional 
Author/Change controller: 

Claudio Petrucci 

DigitPA 

Viale Carlo Marx 31/49 

00137 Roma 

Italy 

EMail: PETRUCCI@digitpa.gov.it 


Specification document: this document, sections 3.1.5, 3.2.2, 
Appendix A. 


8.1.5. Header Field: X-TipoRicevuta: 
Applicable protocol: mail [EMAIL] 


Status: provisional 


Petrucci, et al. Informational [Page 57] 


RFC 6109 Certified Electronic Mail April 2011 


Author/Change controller: 


Claudio Petrucci 

DigitPA 

Viale Carlo Marx 31/49 

00137 Roma 

Italy 

EMail: PETRUCCI@digitpa.gov.it 


Specification document: this document, sections 3.1.5, 3.3.2, 
3302017 3.33225 “31.3253; Appendix- As; 


8.1.6. Header Field: X-Mittente: 


Applicable protocol: mail [EMAIL] 
Status: provisional 
Author/Change controller: 
Claudio Petrucci 
DigitPA 
Viale Carlo Marx 31/49 
00137 Roma 
Italy 
EMail: PETRUCCI@digitpa.gov.it 
Specification document: this document, sections 3.2.3, Appendix A. 
8.2. Registration of LDAP Object Identifier Descriptors 
This document defines new LDAP attributes and object classes for 
object identifier descriptors. As specified and required by 
[LDAP-IANA], this document registers new descriptors as follows per 
the Expert Review. 
8.2.1. Registration of Object Classes and Attribute Types 
Subject: Request for LDAP Descriptor Registration 
Descriptor (short name): See comments 


Object Identifier: See comments 


Person & email address to contact for further information: 
See "Author/Change Controller" 


Usage: See comments 
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Specification: (I-D) 
Author/Change Controller: 


Claudio Petrucci 

DigitPA 

Viale Carlo Marx 31/49 

00137 Roma 

Italy 

EMail: PETRUCCI@digitpa.gov.it 


Comments: 


The following object identifiers and associated object classes/ 
attribute types are requested to be registered. 


OID Descriptor Usage 
12362 Ae La L65122 LL LDIFLocationURLOb ject (0) 
Di 3d. 1657224162 provider 0) 
130.0 04.01. 16512:22..2 1 providerCertificateHash A 
Leds dd LOL Li Liz providerCertificate A 
Leds 1601202. Ze 3 providerName A 
1236.14 Le T6592 .252 4 mailReceipt A 
Vid LOL 232. 5 managedDomains A 
Lrs bs Led 41, 165722426 LDIFLocationURL A 
Ped EP E AS | providerUnit A 
Legend 
O => Object Class 
A => Attribute Type 
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Appendix A. Italian Fields and Values in English 


NOTE: The right column represents a translation of the Italian fields 
for readability’s sake only. Header fields that MUST be used 
are the ones in the left column. 


X-Riferimento-Message-ID Reference Message Identifier 
X-Ricevuta Notification 
non-accettazione non acceptance 
accettazione server-user acceptance 
preavviso-errore-consegna delivery error advance notice 
presa-in-carico server-server acceptance 
rilevazione-virus virus detection 
errore-consegna delivery error 
avvenuta-consegna message delivered 
X-Mittente Sender 
X-VerificaSicurezza Security Verification 
errore error 
X-Trasporto Transport 
posta-certificata certified mail 
errore error 
X-TipoRicevuta Notification Type 
completa complete 
breve brief 
sintetica concise 
certificatore certificator 


Subject values: 


Accettazione SERVER-USER ACCEPTANCE 

Posta certificata CERTIFIED MAIL 

Presa in carico SERVER-SERVER ACCEPTANCE 
Consegna DELIVERY 

Anomalia messaggio MESSAGE ANOMALY 

Problema di sicurezza SECURITY PROBLEM 

Avviso di non accettazione NON ACCEPTANCE PEC NOTIFICATION 
Avviso di non accettazione VIRUS DETECTION INDUCED NON 

per virus ACCEPTANCE PEC NOTIFICATION 
Avviso di mancata consegna NON DELIVERY PEC NOTIFICATION 
Avviso di mancata consegna NON DELIVERY DUE TO VIRUS PEC 
per virus NOTIFICATION 

Avviso di mancata consegna NON DELIVERY DUE TO TIMEOUT PEC 
per sup. tempo massimo NOTIFICATION 
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accettazione 
altro 
avvenuta-consegna 
certificato 
consegna 

data 

dati 

destinatari 
esterno 

errore 
errore-consegna 
errore-esteso 
gestore-emittente 
giorno 
identificativo 
intestazione 
mittente 

no-dest (inatario) 
no-dominio 
non-accettazione 
nessuno 

oggetto 

ora 
posta-certificata 


preavviso-errore-consegna 


presa-in-carico 
ricevuta 
ricezione 
rilevazione-virus 
risposte 

tipo 
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Italian terms in the DID relative to the certification XML file: 


server-user acceptance 
other 

delivered 

certificate 

delivery 

date 

data 

recipients 

external 

error 

delivery error 
extensive error 
transmitting provider 
day 

identifier 

header 

sender 

no recipient 

no domain 

non acceptance 

none 

subject 

hour 

certified mail 
delivery error advance notice 
server-server acceptance 
notification 

receipt (the act of receiving) 
virus detection 
replies 

type 


2011 
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